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The Examiner rejected claims 1-28 and 30-31 as being unpatentable over Weiss (U.S. 
Patent 4,885,778) in view of Kocher (U.S. 6,539,092). The Examiner admits that Weiss does not 
disclose first and second generation values, which are values indicative of a previous number of 
authentication code generations. The Examiner argues that Kocher supplies these elements, in 
the form of transaction counter C, However, even if one assumes that transaction counter C is 
equivalent to first and second generation values, neither Kocher nor Weiss teach or suggest using 
that value in the way required by claim 1 . Specifically, neither Kocher nor Weiss teach or 
suggest: 

. . .generating an authentication code by combining the stored secret, the dynamic value, 
the first generation value, and the PIN. . . 

To explain why neither reference teaches or suggests "combining" Kocher' s transaction 
counter C with Weiss' s stored secret, dynamic value, and PIN, we first address what is meant by 
"combining." The specification and the claims both use the word "combining" in its normal 
sense, i.e., meaning to merge, or to bring into such close relationship as to obscure individual 
characters. For example, the specification provides some non-limiting examples of "combining" 
the secret, dynamic value, and generation value that are consistent with the word's plain 
meaning: 

The combination of the secret (K) the dynamic value (T) and the generation value (N) 
may take place in any order and may use one or more various combination methods. For 
example, in one simplistic embodiment, the values (K,T,N) are EXCLUSIVE-ORed with 
each other to arrive at a resulting authentication code. In another embodiment, the values 
(K,T,N) are provided as input to a one-way function. . . In one of these embodiments, the 
combination function 130 is designed such that each different generation value (N) that is 
combined with a constant stored secret (K) and a dynamic value (T) results in a different 
authentication code value ([0039]). 

In these examples, the stored secret, dynamic value, and generation value are merged to produce 
a single value : the authentication code. 

In contrast, Kocher does not teach or suggest generating an authentication code by 
combining transaction counter C with any other value. Rather, Kocher discloses using 
transaction counter C to update a secret key Kc, e.g., an "authentication code," but Kocher does 
not perform the update process by combining C with any other values. Instead, Kocher's update 
process involves using a rule based on the value of C to select one of "two forward cryptographic 
transformations (F A and F B ) and their inverses (Fa -1 and Fb" 1 )" (col. 2, lines 60-61), applying the 
selected transformation to secret Kc, and incrementing C . Kocher describes the process of 
updating secret key Kc relative to Fig. 1 : 
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At step 100, the client is initialized or personalized with a starting counter C=0 and a 
starting state having a starting secret value Kc=Ko. At step 110, the device performs the 
first transaction, using Kc (or a key derived from Kc). . . 

After step 1 10, the client device's secret value Kc is updated by applying the function F A 
and the counter C is incremented, i.e. by performing O- C+l and Kc<— F A (Kc). (Thus at 
step 1 1 1 , C=l and Kc=F A (Ko).) The updated value of Kc is used to perform a transaction 
at step 1 1 1 (col. 4, lines 37-41 and lines 52-56). 

So, before the transaction at step 1 10, C=0 and Kc=Ko. After the transaction at step 1 10, Kocher 
increments C, so that C=l, and applies F A to starting secret Ko thereby generating an updated 
secret Kc. Then Kc is used for a new transaction at step 111. Kocher describes updating secret 
Kc again after the new transaction: 

After step 1 1 1 , C is incremented again and FA is again applied to KC, i.e. by performing 
C<— C+l and Kc= 2 <— FA(Kc), yielding the secret key used at step 112 (col. 4, lines 56-59). 

In other words, after the transaction at step 111, Kocher increments C, so that C=2, and applies 
F A to the previously used secret Kc thereby generating a newly updated secret Kc. Kocher goes 
on to describe further updating Kc by applying additional functions to it after additional 
transactions: 

The same pair of operations (C+-C+1 and KC<— F A (Kc)) are similarly applied between 
steps 112 and 1 13, and between steps 113 and 114. 

. . .After the transaction at step 1 15, Kc is updated using function F B by incrementing C 
and computing K<- 6 <— F B (Kc). After the transaction at step 116, the secret value for 
transaction 1 17 is computed by applying the function Fb" 1 to Kc (col. 4, lines 59-61 and 
col. 6, lines 1-5). 

So, Kocher updates secret key Kc by applying one of the cryptographic functions F A , F B , Fa" 1 , or 
Fb" 1 to secret key Kc. 

As mentioned above, Kocher selects which cryptographic function to apply to Kc using a 
rule based on the value of C: "The choice of which function to apply in any particular state 
transition can be determined solely as a function of C" (col. 5, lines 33-35). To determine which 
function to apply, Kocher first initializes a temporary counter variable V to the value of C, and 
then determines which function to apply to Kc using a rule based on the value of V. 

At step 230, the device tests whether the variable V is equal to the quantity 2N-3. If 
equal, function FA-1 should be applied, and processing proceeds to step 235 where the 
device increments C and updates KC by computer KC<— FA-l(KC). Otherwise, at step 
240, the device tests whether the variable V is equal to the quantity 2(2N01). If equal, 
function FB-1 should be applied... (col. 6, lines 8-14). 

Kocher goes on to describe the rest of the rules, based on the value of V (i.e., C), for determining 
which one of the functions F A , F B , Fa" 1 , or F B _1 to apply to secret Kc (col. 6, lines 14-24). As 
Fig. 2 illustrates, each time Kocher applies a function to secret Kc, he also increments C. 
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So, Kocher uses rules based on the value of transaction counter C, and increments C. 
Neither of these actions constitute combining C with another value e.g., an authentication code. 

The Examiner argues otherwise, but his arguments are flawed. In the Final Office Action 
dated April 12, 2006, the Examiner argues: 

Kocher thoroughly teaches a security key update process to securely computing, 
for example, a message authentication code by combining, at least a transaction 
counter and a secret value (Kocher: Column 4 Line 39-44) (Final Office Action, 
p. 3). 

However, the section of Kocher to which the Examiner refers does not describe generating secret 
key Kc by combining transaction counter C with a "secret value." Instead, the cited section 
states: 

At step 1 10, the device performs the first transaction, using Kc (or a key derived from 
Kc). The key can be used in virtually any symmetric cryptographic transaction. (For 
example, such a transaction could involve, without limitation, computing or verifying a 
MAC (Message Authentication Code) on a message. . .) (col. 4, lines 39-44). 

So, the section describes an intended use of secret key Kc, e.g., for cryptographic transactions. 
Despite the Examiner's assertions, the section does not disclose "securely computing" an 
authentication code by "combining, at least a transaction counter and a secret value," and indeed 
provides absolutely no insight as to how Kocher generates Kc. Based on the cited section, it is 
even not clear to what "secret value" the Examiner refers. 

In the Advisory Action dated July 1 1, 2006, the Examiner argues that "Kocher is relied 
upon to provide combining another data, i.e., a first generation value (Kocher: Column 2 Line 
47-53, Column 5 Line 4-5 and Column 3 Line 54-60: a transaction counter is considered as 
equivalent to a first generation value"). Again, however, the cited sections do not describe 
"combining" transaction counter C with any other value. The first cited section describes using 
transaction counter C on the server side of a transaction to re-derive the client's secret key: 

To perform a transaction with the client, the server obtains the client's current transaction 
counter (or another key index value). The server then performs a series of operations to 
determine the sequence of transformations needed to re-derive the correct session key 
from the client's initial secret value. These transformations are then performed, and the 
result is used as a transaction session key (or used to derive a session key) (col. 2, lines 
47-53). 

The "sequence of transformations" to which Kocher refers is the application of the functions F A , 
F B , F A _1 , and F B _1 to Kc. The second section the Examiner cites provides an example of 
computing Kc for a new transaction: 
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After the transaction at step 1 1 6, the secret value for transaction 1 1 7 is computed by 
applying the function Fb" 1 to Kc (col. 5, lines 4-5), 

This is simply a specific application of one of the above-described rules for selecting a function 
based on the value of C. Applying the function Fb" 1 does not in any way entail combining C with 
another value. The third section the Examiner refers to describes another variable, D, that 
Kocher uses during his key update process: 

The client also has a (typically non-secret) index or transaction counter C, which may be 
initialized to zero. An additional parameter is an index depth D. The value of D may 
also be non-secret, and (for example) may be client-specific or may be a system-wide 
global constant. The value of D determines the cycle length of the key update process 
(col. 3, lines 54-60). 

The index depth D simply determines "the number of transactions that can be performed before 
the end of the process occurs" (col. 5, lines 50-51). Thus the third cited section simply describes 
two variables used in the key update process. 

In summary, even if one were to combine the teachings of Kocher with the teachings of 
Weiss, the result would not be the claimed invention which requires "generating an 
authentication code by combining the stored secret, the dynamic value, the first generation value, 
and the PIN." Moreover, the Examiner has pointed to nothing, nor could we anything in Weiss 
or Kocher, that suggests or would lead one skilled in the art to employ the transaction counter in 
the way that is required by the claims (i.e., combining it with a stored secret, a dynamic value, 
and a PIN). 

Similar reasoning applies to claim 17 which recites: 

a combination subsystem generating an authentication code by retrieving the secret from 
the memory element and combining the secret and the dynamic value from the dynamic 
value subsystem, the PIN received by the PIN subsystem, and the generation value from 
the generation value subsystem . 

As discussed above, Kocher does not teach or suggest generating an authentication code by 

combining a generation value with any other value. Thus, Kocher also does not teach or suggest 

a combination subsystem that performs this function. 

For the reasons stated above, we submit that the application is in condition for allowance, 
and therefore ask that the claims be allowed to issue. 
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